java-analyzer-bundle.test/META-INF/MANIFEST.MF (1)

5-6: Consider aligning Fragment-Host version constraint with the new bundle line.

After bumping Bundle-Version to 1.1.0.qualifier, keeping Fragment-Host: ...;bundle-version="1.0.0" may unintentionally allow attachment to older host lines than intended. If this fragment is only validated for the 1.1.x line, tighten the host version accordingly.

Suggested manifest adjustment

-Fragment-Host: java-analyzer-bundle.core;bundle-version="1.0.0"
+Fragment-Host: java-analyzer-bundle.core;bundle-version="1.1.0"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@java-analyzer-bundle.test/META-INF/MANIFEST.MF` around lines 5 - 6, The
Fragment-Host version constraint should be tightened to match the new
Bundle-Version to prevent attaching to older hosts: update the Manifest's
Fragment-Host attribute (the line beginning with "Fragment-Host:
java-analyzer-bundle.core;bundle-version="1.0.0"") to the appropriate 1.1.x
range (e.g., "1.1.0" or "1.1.0.qualifier" or a range like "[1.1.0,2.0.0)") so it
aligns with the updated Bundle-Version ("Bundle-Version: 1.1.0.qualifier");
change only the bundle-version value on the Fragment-Host line to enforce the
intended host compatibility.

.github/workflows/post-release-bump.yaml (2)

79-87: Consider adding error handling for branch conflicts.

If the workflow runs twice for the same version (e.g., re-tagging), git push origin "$BRANCH" could fail if the branch already exists. Consider adding --force or checking for existing branches/PRs.

Proposed fix to handle existing branches

       - name: Create branch and commit
         run: |
           NEXT="${{ steps.next_version.outputs.next_version }}"
           BRANCH="chore/bump-version-${NEXT}"
+          # Delete remote branch if it exists (handles re-runs)
+          git push origin --delete "$BRANCH" 2>/dev/null || true
           git checkout -b "$BRANCH"
           git add -A
           git commit --signoff \
             -m "chore: bump version to ${NEXT} after ${{ github.ref_name }} release"
           git push origin "$BRANCH"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/post-release-bump.yaml around lines 79 - 87, The branch
creation/push step can fail if BRANCH already exists; update the logic around
the BRANCH variable and the git push command so the workflow handles existing
branches (e.g., check for an existing remote branch named "$BRANCH" before
creating or use git push --force-with-lease to update safely), and ensure the
git checkout -b "$BRANCH" / git commit sequence is skipped or uses git checkout
"$BRANCH" when the branch already exists; locate and modify the block that sets
NEXT/BRANCH and runs git checkout -b, git push origin "$BRANCH" to implement the
existence check or safe force push.

---

89-116: Consider adding --fill or duplicate PR detection.

If the branch already exists with an open PR (from a previous failed run), gh pr create will fail. Consider checking for existing PRs first.

Proposed fix to handle existing PRs

       - name: Create Pull Request
         env:
           GH_TOKEN: ${{ steps.get_workflow_token.outputs.token }}
         run: |
           RAW="${{ steps.next_version.outputs.raw_version }}"
           RELEASE="${{ steps.next_version.outputs.release_version }}"
           NEXT="${{ steps.next_version.outputs.next_version }}"
+          BRANCH="chore/bump-version-${NEXT}"
+          
+          # Check if PR already exists
+          EXISTING_PR=$(gh pr list --head "$BRANCH" --json number --jq '.[0].number' || true)
+          if [ -n "$EXISTING_PR" ]; then
+            echo "PR #${EXISTING_PR} already exists for branch ${BRANCH}, skipping creation"
+            exit 0
+          fi
+          
           gh pr create \
             --title "chore: bump version to ${NEXT}" \

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/post-release-bump.yaml around lines 89 - 116, The GH CLI
step using gh pr create can fail if a branch or PR already exists; modify the
workflow around the gh pr create invocation to detect and handle existing PRs
for the target branch (--head "chore/bump-version-${NEXT}"). Update the script
to first query existing PRs (e.g., gh pr list or gh api with
GH_TOKEN/steps.get_workflow_token.outputs.token) filtering by head branch name
${NEXT}/"chore/bump-version-${NEXT}", and if a matching open PR exists skip
creation (or call gh pr edit) — alternatively use gh pr create --fill where
appropriate; ensure the logic is applied in the block that references RAW,
RELEASE, NEXT and the gh pr create command so duplicate-PR failures are avoided.

Makefile (1)

96-102: Consider whether set-version should also be a dependency of build-container.

Currently build-container passes BUNDLE_VERSION to Docker but doesn't depend on set-version. If someone runs make build-container BUNDLE_VERSION=1.2.0 without running set-version first, the local Maven artifacts might have mismatched versions.

However, since Dockerfile handles version-setting internally during the build, this may be intentional. If the local Dockerfile.test workflow is expected to use pre-built JARs, consider documenting this distinction.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@Makefile` around lines 96 - 102, The build-container target may produce
images with mismatched Maven artifacts because it uses BUNDLE_VERSION but does
not depend on the set-version target; update the Makefile so the build-container
target depends on set-version (add "build-container: set-version" or include
set-version in its dependency list) to ensure local artifacts match the passed
BUNDLE_VERSION, and if the Dockerfile intentionally sets versions during image
build (or Dockerfile.test uses pre-built JARs), add a short comment above the
build-container target explaining that behavior instead of changing
dependencies.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

.github/workflows/post-release-bump.yaml (1)

40-52: translate_version function differs from image-build.yaml - consider extracting to shared script.

This translate_version implementation lacks the pre-release suffix handling (-rc.1, -alpha.2) that exists in .github/workflows/image-build.yaml (lines 36-55). While the workflow correctly skips pre-release tags via the if condition at line 13, keeping these functions consistent would improve maintainability.

Consider extracting the version translation logic to a shared shell script (e.g., scripts/translate_version.sh) that both workflows can source.

♻️ Proposed fix to add suffix handling for consistency

          translate_version() {
-           local raw="$1" base
-           IFS='.' read -r major minor patch <<< "$raw"
+           local raw="$1" base suffix=""
+           # Separate pre-release suffix (e.g., -rc.1, -alpha.2)
+           if [[ "$raw" == *-* ]]; then
+             suffix="-${raw#*-}"
+             base="${raw%%-*}"
+           else
+             base="$raw"
+           fi
+           IFS='.' read -r major minor patch <<< "$base"
            if [[ "$major" -ge 1 ]]; then
-             echo "${raw}"
+             echo "${base}${suffix}"
            elif [[ "$minor" -ge 10 ]]; then
-             echo "1.$((minor - 9)).${patch}"
+             echo "1.$((minor - 9)).${patch}${suffix}"
            elif [[ "$minor" -eq 9 && "$patch" -ge 1 ]]; then
-             echo "1.0.$((patch - 1))"
+             echo "1.0.$((patch - 1))${suffix}"
            else
-             echo "${raw}"
+             echo "${base}${suffix}"
            fi
          }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/post-release-bump.yaml around lines 40 - 52, The
translate_version function in this workflow is inconsistent with the one in
image-build.yaml and lacks pre-release suffix handling; extract the logic into a
shared shell script (e.g., scripts/translate_version.sh) that implements the
same transformation as image-build.yaml including detection and preservation of
pre-release suffixes (like -rc.1, -alpha.2) and the numeric translation rules,
then replace the inline translate_version definitions in both workflows with
sourcing of that script and calling the shared translate_version function to
ensure consistent behavior and single-point maintenance.

java-analyzer-bundle.test/integration/client/jdtls_client.go (1)

191-194: Consider deriving the plugins path from jdtlsPath instead of hardcoding.

The path /jdtls/plugins is hardcoded here, but the JDTLSClient already stores jdtlsPath. This could cause issues if the JDT.LS installation is at a different location.

♻️ Proposed fix to use dynamic path

 		InitializationOptions: map[string]any{
-			"bundles":          findAnalyzerBundles("/jdtls/plugins"),
+			"bundles":          findAnalyzerBundles(filepath.Join(c.jdtlsPath, "plugins")),
 			"workspaceFolders": []string{string(workspaceURI)},
 		},

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@java-analyzer-bundle.test/integration/client/jdtls_client.go` around lines
191 - 194, The bundles path is hardcoded as "/jdtls/plugins" but JDTLSClient
already holds the installation path in jdtlsPath; update the call to
findAnalyzerBundles inside the InitializationOptions map to derive the plugins
directory from the client's jdtlsPath (e.g., use filepath.Join(jdtlsPath,
"plugins") or path.Join depending on imports) instead of the literal string,
ensuring you reference the JDTLSClient receiver/field (jdtlsPath) and keep the
rest of the map (workspaceFolders) unchanged.

java-analyzer-bundle.test/docs/integration-tests.md (1)

482-482: Add language specifier to fenced code block.

The fenced code block lacks a language specifier. Since this shows test output, use text or plaintext for proper markdown rendering.

📝 Proposed fix

-```
+=== RUN   TestDefaultSearch
+```text
+=== RUN   TestDefaultSearch

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@java-analyzer-bundle.test/docs/integration-tests.md` at line 482, The fenced
code block that contains the test output for "TestDefaultSearch" is missing a
language specifier; update the triple-backtick fence surrounding the block that
starts with "=== RUN   TestDefaultSearch" to use a plaintext/text specifier
(e.g., change ``` to ```text) so the test output renders correctly in markdown.